This is not an ideal solution, likely we should be sure we're doing poly1305 right and expose it from here.

I'll remove serde from this repo eventually ala #73, so serde should not be used here, and should be avoided for crypto in general.

We do need serialization of course, but this should be done directly as binary, probably little endian.

I see.. You added an extra round so everyone could encrypt to everyone else's f(0) G.

Any idea what blockstream did here? We must treat some input as "PKI", either

1. we save ourselves a round by making the user supply encryption keys initially, or else
2. make the user provide the round 1 messages from the right people.

I think 1 looks more robust, in the sense that if they provide us a bad public key, then they're clearly buffoons, while 2 requires they do some checking all by themselves.

Blockstream follows 1.

The idea is that you do not really save a round because you still need to somehow know the encryption keys of the participants, you just save a round in this protocol.

And because of that, it excludes use cases where there is no way of knowing those keys beforehand, or they do not exist.

That being said, I do not have a concrete use case and maybe it is not relevant.

Edit: This does not make sense, since you still need an authenticated channel to send the first messages in a secure way, which requires some keys.

I mentioned session types way back, meaning this struct should not be clone or serialization, and it shiould be consumed by value later. It's fine if a specific signer device must change this code themselves.

It's also possible it doesn't matter enough here, soi maybe not worth bothering.

Yeah, I added because I needed them for the tests and benchmarks...Maybe we can add them only as an internal feature?

In fact, we could immediately trash this data if we fix the encryption and make a two phase sender & reciever thing like I discuss elsewhere.